\chapter{Introduction}
\label{chapter:introduction} 

Web service is a paradigm that aims to implement architectures via Web. A web
service is a logically atomic component that provides operations through a
standardized interface. The particularity of a platform for web services is use the Internet high-level
protocols as an infrastructure for communication between software components. Web services use a
structure based on three major technologies, namely: a communication protocol (SOAP - \textit{Simple Object Access Protocol)}
 \cite{soap}), an interface description language for services (WSDL -
 \textit{Web Service Definition Language} \cite{wsdl}) and a specification for
 publishing and finding services (UDDI - \textit{Universal Description,
 Discovery and Integration} \cite{uddi}). This architecture model defines the 
 software components as a collection of processing units that communicate via
 messages.

It is possible create new services from existing ones, adding value to the
compositions. Thus, the composition defines an implementation process where the
result is the creation of a new service whose activities are processed by
components of other web services.
 
The infrastructure of web services is limited to a simple collection of
operations that can be easily accessed from web messaging, thus this paradigm
favors the writing process, making it transparent to the user of the services to
implement them. However, some composition processes require more complex
interactions of services. In fact, for a more complex implementation is
possible, it is necessary an adequate description of the interface that
expresses the composite services.    
<<<<<<< .mine
=======

Some research initiatives attempt to define description languages
for services, because WSDL description specify only static aspects. The
dynamic characteristics of services can be described in different ways,
depending on the technology used. The new proposals extend the WSDL
specification by adding behavioral characteristics, such as \textit{PEWS \cite{BaCAM05}, BPEL4WS \cite{bpel03}, XLANG \cite{xlang},
WSCI \cite{wsci}} e \textit{OWL-S \cite{owl04}}. Other works propose
quality models, \textit{frameworks} and APIs to support the development of
service-based applications, integrating languages and development
environments.

The use of many different platforms and APIs for the development of
Web applications raises the need for an infrastructure that
allow an organized execution of the analysis activities , design and
implementation of software using patterns implementation, thus enabling the creation of secure, reliable
and quality applications. The  developing application process o which make use
of web services is done in a \textit{ad hoc} way, without follow
methods that will ensure the requirements that the application 
needs. The purpose of a new method for reliable applications is
to improve its development, enabling the use of different
models and APIs in order to increase productivity and reuse of components.   

>>>>>>> .r110
Current standards in service composition implement functional, non-functional
constraints and communication aspects by combining different languages and
protocols. WSDL and SOAP among others are languages used respectively for
describing services' interfaces and message exchange protocols for calling
methods exported by such services. For adding a transactional behaviour to a
service composition it is necessary to implement WS-Coordination,
WS-Transaction, WS-BussinessActivity and WS-AtomicTransaction. The selection of
the adequate protocols for adding a specific non-functional constraints to a
service composition (e.g., security, transactional behaviour and adaptability)
is responsibility of a programmer. As a consequence, the development of an
application based on a service composition is a complex and a time-consuming
process. This is opposed to the philosophy of services that aims at facilitating
the integration of distributed applications.

MDA (Model Driven Architecture) \cite{miller} is an important approach for alignment
between high-level information modelling, non-functional requirements and service-based
developement, bacause MDA provides a conceptual structure that extends from the models used by system
analysts to different models used by software developers. MDA also provides,
through transformation of models, the likelihood that the specified elements in a diagram may be
converted, automatically, in other elements of more detailed diagrams which are
derived from it.

The MDA approach allows the system specification as an abstract model,
which may be realized as a concrete implementation (program) for a particular
service platform (e.g. WSDL, BPEL or PEWS). So, an service-based application
that has been successfully developed via a MDA approach could be ported to
different platforms. Considering code generation, it means that from a MDA
method it is possible to generatem from abstract models solutions, the
source code for the software system. The method provides a skeleton of the
program source code, in the form of a source code template where predefined
tokens are then replaced with program source code parts during the code
generation process. MDA methods separete design from architecture. The design
addresses the functional requirements while architecture provides the non-functional
requirements like scalability, reliability and performance are realized.   

Considering MDA development, intermediate models that are used to produce the
final realization are also considered final products of the development process.
These models are carefully  efined so as to remain stable in face of changes in
platform technologies, and are therefore called platform-independent models
(PIMs) \cite{miller}.

Based on the context, our approach intends to combine service-based
development, non-functional aspects and model driven architecture (MDA) so that
reliable service-based systems can be developed in a platform independent
manner and generated from high level models. In the current chapter we describe
the main motivations, objectives, contributions, the problem we address, and
what are our propositions.

  
\section{Motivation}

Service oriented computing is at the origin of an evolution in the field of software development. 
An important challenge of service oriented development is to ensure the
alignment between IT systems and the business logic. Thus, organizations are 
seeking for mechanisms to deal with the gap between the systems developed and
business needs \cite{bell}. The literature stresses the need for methodologies
and techniques for service oriented analysis and design, claiming that they are
the cornerstone  in the development of meaningful service based applications
\cite{5}.  In this context, some authors argue that the convergence of
model-driven software development, service orientation and better techniques for
documenting and improving business processes are the key to make real the idea
of rapid, accurate development of software that serves, rather than dictates,
software users' goals \cite{watson}.

Service oriented development methodologies providing models, best practices, and
reference architectures to build service based applications mainly address 
functional aspects \cite{1,2,decastro1,PapazoglouH06}.  Non-functional aspects
concerning service and application's ``semantics", often expressed as
requirements and constraints in general purpose methodologies, are not fully
considered or they are added once the application has been implemented in order
to ensure some level of reliability (e.g., data privacy, exception handling,
atomicity, data persistence). This leads to service based applications that are
partially specified and that are thereby partially compliant with application
requirements.         
 
Considering these problems, our work proposes a methodology for reliable
service-based application development. The methodology is MDA-based and proposes
a set of models to development of system. The methodology is named $\pi$SOD-M
(\textit{Policy based Software Oriented Development Methodology}). $\pi$SOD-M
(i) extends the SOD-M \cite{decastro1} method with the notion of {\em Policy}
\cite{Espinosa-Oviedo2011a} for representing non-functional constraints associated to service based applications; (ii)
defines the \textit{$\pi$-PEWS}  meta-model \cite{Placido2010LTPD} providing
guidelines for expressing the composition and the Policies; and finally,
 (iii) defines model to model transformation rules for generating the
 \textit{$\pi$-PEWS} model of a reliable service composition starting from the extended service composition model; and, model to text transformations for generating
 the corresponding implementation. As will be shown within our environment
 implementing these meta models and rules, one may represent both systems'
 cross-cutting aspects (e.g., exception handling for describing what to do when
 a service is not available, recovery, persistence aspects) and constraints
 associated to services, that must be respected for using them (e.g., the fact
 that a service requires an authentication protocol for executing a method).

\section{Objectives}


% The objective of this work is to model non-functional
% constraints and associate them to service-based applications
% early during the service composition modeling phase. Therefore
% we present $\pi$SOD-M, a model-driven method for building reliable services'
% based information systems (SIS).
 
% Our work (i) proposes to extend the SOD-M \cite{valeriaThesis} method
% with the notion of A-Policy \cite{Espinosa-OviedoVZC09,Espinosa-Oviedo2011a} for
% representing non-functional constraints associated to services' based applications;
% (ii) defines the $\pi$PEWS meta-model \cite{BaCAM05,Placido2010LTPD} providing
% guidelines for expressing the composition and the A-policies;
% and finally, (iii) defines model to model transformation rules
% for generating  reliable services' composition starting from the use case model
% to services' composition model; and, model to text transformations for generating
% the corresponding implementation. As will be shown within
% our environment implementing these meta models and rules,
% one may represent both systems' cross-cutting aspects (e.g.,
% exception handling for describing what to do when a service
% is not available, recovery, persistence aspects) and constraints
% associated to services, that must be respected for using them
% (e.g., the fact that a service requires an authentication protocol
% for executing a method). 

The main objective of this doctoral thesis focuses
on two specific points in the software engineering context, they are: (i)
non-functional requirements modeling for reliable web service applications and
(ii) improving software process development for web services applications. 

 This approach facilitates the development of service-oriented
applications as well as their implementation using current technologies, e.g.
web services. The main methodology features are:
 
\begin{itemize}
  \item \textbf{Development based on non-functional requirements:} 
  The methodology $\pi$SOD-M's main feature is the modeling and application
  development with a focus on non-functional requirements. The whole structure
  of the methodology focuses on concepts and definition of non-functional requirements.
  A non-functional requirement (NFR) specifies criteria about the operation of a
  system. The NFRs should be contrasted with functional requirements that define
  specific behavior or functions of a system.
  \item \textbf{Classification of non-functional requirements for web services:}
  Other $\pi$SOD-M feature is a classification for modeling non-functional
  requirements for web services. This classification is based on an analysis of
  the key features in the development of trusted applications for services.
  Associate non-functional requirement to services' composition help to
  ensure that the resulting application is compliant to the user requirements
  and also with the characteristics of the services it uses and that they are
  reliable and ensure non-functional properties is a challenge in developing
  application. To adapt quality properties in the web service development
  context can provide a greater software reuse.
  \item \textbf{Set of specific concepts for reliable service-oriented
  development:}  $\pi$SOD-M defines a set of concepts organized according to three
points of view: (\textit{i})  \textit{policy view}, focusing
on the non-functional requirements expressed by policies,
(\textit{ii}) \textit{business view}, focusing on the features and the
requirements of the business, and (\textit{iii}) the \textit{system
view}, concentrating on the functionalities and processes that need to be implemented
in order to satisfy the business requirements. The modelling process of
$\pi$SOD-M includes models that are in correspondence with: (a) the three
different abstraction levels considered by MDA: \textit{(a)} CIM, PIM and PSM
and \textit{(b)} the $\pi$SOD-M views: the business, system  and
policy views.
  \item \textbf{MDA based approach:} The method follows an MDA-based approach, proposing a set of
models extending from the PIM level to the PSM levels. For the CIM level,
we consider a business and requirements specification document, and important
data for modeling the application. As the method is an extension of SOD-M \cite{CastroMV11}, the
value and business models are still considered, without, however, be extended with
the concepts of non-functional requirements. Thus, by means of mapping rules,
$\pi$SOD-M provides the benefits of the alignment of high-level business processes with the
technologies currently available for deploying the service-oriented paradigm.
$\pi$SOD-M considers the development of applications with focus on
non-functional requirements from the early stages of development.
\item \textbf{UML as modeling language:} $\pi$SOD-M UML profile includes all
  the modeling needed at PIM level for the development of systems from a
  service-oriented perspective. We also extend the original UML profile that can
  be used for modeling non-functional characteristics through stereotypes.  
\end{itemize}
  

\section{Contributions}

\section{What This Thesis is Not About}

\section{Document Structure}

  
